Introduction au CI/CD

École Nationale des Sciences Géographiques

Décembre 2017 - Damien DUPORTAL

Creative Commons License

This work is licensed under a http://creativecommons.org/licenses/by/4.0/

Bonjour !

Damien DUPORTAL

damien

Et vous ?

commitstrip

Objectifs

Objectifs

TBD.

Evaluation

Evaluation

TBD.

Source Code Management (SCM)

"Gestion de Code Source"

Qu’est ce que le SCM ?

Les Gestionnaires de Code Source, également connus comme "Version Control Systems" (VCS):

  • Sont des systèmes logiciels

  • Conservent toutes les modifications apportées à une collection de fichiers, dans le temps

  • Permettent de partager ces changements

  • Fournissent des fonctionnalités de merge et de suivi des modifications

Pourquoi les SCM ?

  • Pour collaborer efficacement sur un même référentiel de code source

    • Aide à la résolution de conflits

    • Partage de contenu facile

  • Pour conserver une trace de tous les changements : On parle de source unique de vérité (Single Source of Truth)

    • Historique complet des modifications

    • Possibilité de retour arrière à tout moment

Quels sont les types de SCM ?

  • Locaux

  • Centralisés

  • Distribués

SCM Locaux

scm local

  • Plus vieux type, ancêtre de tous les autres

  • Uniquement historique de modification

    • Utilise une "base de donnée de versions" des fichiers

    • Stockage uniquement des différences ("diff")

  • Pas de partage

  • Exemple: rcs (toujours dans Apple XCode Tools)

SCM Centralisés (CVCS)

  • Couvre historique ET partage

    • La "base de données de versions" est stockée sur un serveur central

  • Chaque client ne possède qu'une seule version du code

scm centralized

  • Apprentissage très facile, limité sur la résolution de conflits

  • Exemples: CVS, SVN, Perforce, TFS

SCM Distribués (DVCS)

  • La "base de données de versions" est distribuée par duplication sur chaque noeud

  • Exemples: Git, Mercurial, Bazaar, Monotone

scm distributed

Comment héberger son SCM ?

  • Hébergés dans le Cloud

  • Hébergé "à la maison"

SCM "Hébergés dans le Cloud"

  • SCM as a Service

  • Le serveur centralisé est un service hébergé par un fournisseur

  • Avantages:

    • Pas de temps/énergie passés sur la gestion

    • Associent au SCM d’autre services : gestionnaire de tickets, wiki, éditeur de texte online, etc.

  • Risque: Votre code est hébergé par un tiers

  • Exemples: GitHub, Bitbucket by Atlassian, Amazon CodeCommit, Visual Studio Online by Microsoft, SourceForge, GitLab.com, etc.

SCM "Hébergés dans le Cloud"

  • Pour pallier au risque précédent, on trouve des versions "On-Premide" (généralement payantes)

  • Le monde de l’Open Source fourni également des solutions à héberger soit-même

    • Très souvent gratuit et on peut le corriger

    • Temps et énergie à consacrer

  • Exemples: Gitlab, Gitea, Gogs, Bazaar server, VisualSVN Server, etc.

Terminologie des SCM : Basiques

  • diff: un ensemble de lignes "changées" sur un fichier donné

  • changeset: un ensemble de "diff" (donc peut couvrir plusieurs fichiers)

  • commit: Action de sauvegarder un changeset dans la base de données des versions.

Terminologie des SCM : Représentation

  • Le dernier commit dans l’historique est aliasé comme "HEAD"

scm basics legend
scm basics history

Terminologie des SCM : Branches

  • Abstraction d’une version "isolée" du code

  • Concrètement, une branche est un alias pointant vers un "commit"

scm branches

Terminologie des SCM : Merge

  • On intègre une branche dans une autre en effectuant un merge

    • Un nouveau commit est créé, fruit de la combinaison de 2 autres commits

scm merge

Terminologie des SCM : Pull Request

  • Une Pull Request (ou "Merge Request") est une procédure de revue de code avant intégration

scm pull request

Motifs d’utilisation des SCMs ?

Voici quelques motifs d’utilisation des SCMs :

  • "Centralized" Flow

  • "Feature Branch" Flow

  • "Git" Flow

  • "GitHub" Flow

Centralized Flow

scm centralized flow how to

Feature Branch Flow

  • Une seule branche par fonctionnalité

scm feature branch workflow

Git Flow

scm git workflow

GitHub Flow

github flow

Résoudre des problèmes avec le SCM

Pour aller plus loin…​

Un peu de lecture :

Tests Logiciels

Pourquoi tester un logiciel ?

Qu’est ce que le "test logiciel" ?

  • Le test logiciel est une pratique suivant 2 piliers :

    • Valider que le logiciel remplisse les rôles qui lui sont confiés

    • Rechercher les fautes pour les corriger, améliorant la qualité du système

Tests Automatisé ou Manuels ?

  • Automatiser : répétition et reproductibilité

  • Test Manuel à considérer dans peu de cas, quand :

    • Coût de l’automatisation dépasse sa valeur

    • Automatisation impossible

Terminologie du Test Logiciel

  • SUT: "System Under Testing". Défini les frontières du système.

  • Test Double: Terme générique désignant un sous-ensemble simplifié du "S.U.T.". Exemples: Mock, Stub, Spy, etc.

  • Boîte Blanche: Tester avec une vue interne du SUT

  • Boîte Noire: Tester le SUT sans connaissance préalable de ses mécanismes interne

Comment tester le logiciel ?

  • La question primordiale est: "Que voulez-vous tester ?"

  • En fonction de la réponse, différent types de tests peuvent être utilisé (liste NON exhaustive) :

    • Unit testing

    • Integration testing

    • Smoke testing

    • Functional Testing

    • Non-Regression testing

    • Acceptance testing

Test Unitaire

  • Focalisé sur le plus petit sous sytème possible du SUT, en "boîte blanche"

  • Tests indépendants les uns des autres

    • Ordre d’exécution non important

    • Utilisation de Test Doubles pour simuler le "reste" en bon fonctionnement

test unit

Tests d’Intégration

  • Vérifier l’intégration entre différents sous-systèmes

  • Le SUT est en "boîte blanche"

test integration

Smoke Testing

test smoke

  • But : Fail Fast en "boîte blanche"

  • Valide les fonctions "de base" du système

  • On parle parfois de "Sanity Checking"

If it smokes, it’s bad
— Anonymous Electrician

Tests Fonctionnels

  • Vérifie que le logiciel se comporte comme prévue par les personnes en charge de la fabrication

  • Pas de biais d’inteprétation

  • Le SUT est en "boîte noire"

Tests de Régression

  • Vérifie que le SUT a un comportement stable dans le temps

  • Focalisation sur bug qui ne doit pas revenir

  • Le SUT est en "boîte noire"

test regression
Correcting a single bug may introduce several more.
— Any developer

Tests d’Acceptation

  • Également connu sous l’acronyme "UAT" User Acceptance Testing

  • Vérifie que le logiciel se comporte comme attendu par l’utilisateur

  • Biais de communication inclus

  • Le SUT est en "boîte noire"

test acceptance

Ordre des Tests

  • Fonction des temps d’exécutions, des coûts de corrections, et des valeurs ajoutées. Contextuel.

test pyramid

Test Driven Development

  • TDD: Écrire les tests unitaires avant le code

tdd

Behaviour Driven Development

  • BDD: Privilégier language naturel et interactions

    • "Given, When, Then"

    • Moins de technique. Valeur ajoutée pour l’utilisateur.

bdd

Pour aller plus loin…​

"Continuous Everything"

Qu’est ce que l’Intégration Continue ?

Continuous Integration is a software development practice where members of a team integrate their work frequently. Usually each person integrates at least daily - leading to multiple integrations per day.

— Martin Fowler - Continuous Integration

Intégration Continue (CI)

fail fast continuous integration

  • Construire et intégrer le code en continu

  • Le code est intégré souvent, au moins quotidiennement pour que l’intégration soit un non-évenement

  • Chaque intégration est validée par une construction automatisée avec tests

Pourquoi la CI ?

But : Détecter les fautes au plus tôt

big bugs

Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.

— Martin Fowler

Livraison Continue

Continous Delivery (CD)

Pourquoi la Livraison Continue ?

  • Diminuer les risque liés au déploiement

  • Permettre de récolter des retours utilisateurs plus souvent

  • Rendre l’avancement visible par tous

How long would it take to your organization to deploy a change that involves just one single line of code?

— Mary and Tom Poppendieck

Qu’est ce que la Livraison Continue ?

  • Suite logique de l’intégration continue:

    • Chaque changement est potentiellement déployable en production

    • Le déploiement peut donc être effectué à tout moment

Your team prioritizes keeping the software deployable over working on new features

— Martin Fowler

Déploiement Continu

Continuous Deployment

Qu’est ce que le Déploiement Continu ?

  • Version "avancée" de la livraison continue:

    • Chaque changement est déployé en production, de manière automatique

  • Question importante: En avez-vous besoin ?

    • Avez-vous les mêmes besoin que Amazon Google ou Netflix ?

Continuous Delivery versus Deployment

continuous depl vs delivery

Pour aller plus loin…​

Chaîne Logistique du Logiciel

"Software Supply Chain"

La boucle de rétroaction

"Feedback loop" / "Boucle de feedback"

Pourquoi de la rétroaction ?

  • Problèmatique : réagir rapidement pour corriger une faute

    • "Au plus tôt, au moins cher"

  • Problème #1: Avoir un retour

  • Problème #2: Réagir systématiquement sur un retour

  • Problème #3: Avoir confiance

Qu’est ce qu’une boucle de Feedback ?

feedback loop

Comment implémenter la rétroaction ?

  • Quels acteurs du système ?

  • Quel médium de communication ?

  • Quel déclencheurs et quelles limites ?

  • Culture à construire, les outils suivent facilement

Chaîne Logistique du Logiciel

supply chain

The Pipeline

pipeline

Qu’est ce qu’un Pipeline ?

  • Industrialisation du logiciel

  • Modélisation de la chaîne de valeur ("Value Stream Mapping")

  • "Fast is cheap": Piloté par le concept de la défaillance rapide ("fail fast")

Anatomie d’un "Pipeline" 1/2

  • Stage ("étape"): Élément de base

    • Abstraction atomiques d’un ensemble d’actions

    • Exemple: "Build", "Run Unit Tests"

    • Possibilité de parallèlisation

  • Gate ("Porte"): Transition entre 2 étapes

    • Manuel ou automatique

    • Peuvent être conditionnelles

Anatomie d’un "Pipeline" 2/2

  • Déclenchement initial : un changement dans la base de code

  • Chaque étape peut produire des livrables: on parlera d'Artefacts dans ce cours

Etapes de "Deploiement"

  • Le déploiement est ce qui permet de rendre le logiciel prêt à l’usage

  • Un "déploiement" est exécuté vers un environnement

    • Production

    • Préproduction ("staging") / recette ("qualification")

    • Tests

    • "Disaster Recovery Environment"

Un example de Pipeline

cd pipeline example

Comment faire des "bons" Pipelines ?

  • Commencer par un "Produit Minimum Viable" (MVP) puis itérer

  • S’efforcer d’appliquer les bonne pratiques

  • Optimiser le Pipeline (lors des itérations)

Bonnes Pratiques

  • Réutilisation des artefacts: "Only Build Your Binaries Once"

  • Arrêt du Pipeline dès qu’une faute est identifiée: "Fail Fast"

    • Identifier si un artefacts n’est pas déployable (tests…​)

  • S’assurer qu’une même version de la base de code est utilisée à tout moment pour un Pipeline donnée

Optimiser le Pipeline

cd pipeline wait

  • Paralléliser les étapes

    • Arrêt du Pipeline si une "branche" est en erreur

    • Sinon: étape inutile à supprimer

  • Les "gates" manuelles peuvent également être paralleliser

    • relation "1-N": N "gates" manuelles déclencheront N étapes parallèles

Exemple de Pipeline optimisé

cd pipeline optimized example

Pour aller plus loin…​

Un peu de lecture :

Security

Why do Security ?

  • Your organization uses information to create value

  • Information is valuable and must follow:

    • Confidentiality

    • Integrity

    • Availability

  • Implementing Security practices envorce those rules

What is Security ?

  • Security is the set of practices and tools to fight and prevent threats

  • It’s all about following those principles:

    • Know the system

    • Least privilege: If you do not need to do it, you do not have the right to do it.

    • Defense in Depth: Systems are layered. Put security on all layers.

    • Preventing is good. Detection is better: Continuous monitoring and detection.

How to do security ? Least privilege

  • Handling "Least privileges" concepts makes you manage the AAA concepts:

    • Authentication

    • Authorization

    • Accounting

Authentication

  • Authentication is the set of tools and procedures that identify a user with enough confidence

    • When police check your ID, it is authentication

    • Using a login and a password is an authentication

    • Biometrics are also a type of authentication

    • 2FA, that stands for "Two Factor Authentication" is a stronger authentication scheme

security authentication

Authorization

  • Once a given user is authenticated, need to determine the actions this user should have the right to do

  • Authorization always occurs in the context of authentication

  • Authorization grants access rights to:

    • Resources: Tasks, objects and/or actions to manipulate

    • Roles: A set of rights grouped together by commodity

    • Requesters: User or group that has roles assigned, and wants to manipulates resources

  • It is easy to visualize and enforce with a Security Matrix

Accounting

  • Occurs in the context of a user both authenticated and authorized.

  • It measures resources used or consumed by the user during access.

  • This can be amount of data, compute resources, or system time.

  • It enforces limits when they are defined to protect system.

  • Related to system measurement, capacity planning and feedback loops

How to do security ? Defense in Depth:

  • Defense in Depth is not an easy subject, but we are focusing on the Credentials

    • Given the previous AAA context

    • A lot of systems for stages of pipelines (SCM, CI Server, Environment, WebServices, etc.)

    • How to enforce homogeneity of AAA ?

  • Credential management is the practices and tools that avoid leaking authentication information to non authorized users.

How to do security ? Detection is better

  • Security has to be meta: how to enforce security itself ?

  • Auditing the security processes and system is a method to validate them.

  • It can be seen as a type of Acceptance Testing:

    • Needs to be run continuously

    • Should be done by someone other than the user being audited

    • It can be related to external certification for external confidence (e.g. PCI)

What did we learn ?

  • Security is a required discipline that must be taken into account from the beginning

  • It is a large subject but enforcing the rules is a big win

  • Implementing AAA framework is a good way to start

  • Security is related to feedback: which action to take when a problem arises ?

  • Measurement is not an option, but a must have

Going further

Some recommended readings on this subject: